Problem

• An agent asking "what has this scanner found?" cannot call vision-scanners-observations-list at its documented default. The page overflows the exec token cap, so every caller has to guess a small limit first.
• Three fields on each row carry no per-row information:

• Verified on a live monitor scanner on 2026-09-06: a 3-row page repeated the same 3,071-character prompt three times, over 9,200 characters of repetition from one static field.
• Reported on 2026-07-04. #68360 implemented a fix and the stale bot closed it unmerged on 2026-08-13, with no review objection. Nothing has changed for a caller since.

Changes

• The tool's default page is now 20 observations, and its rows no longer repeat the prompt, the query, or the duplicated reasoning segments. An agent can call it with no arguments and read the result.
• The tool description and agent note now send a caller to vision-scanners-observations-get for one observation's full prompt and citation timestamps, so deep-linking a moment still works, at one extra call per finding.
• The trim sits in the MCP layer rather than the serializer, which is where #68360 put it. That closed PR would have broken four app surfaces that read these same fields off list rows: the scanner observations table and calibration tab (prompt tooltip on monitor and scorer rows), the replay dock and player sidebar (CitedText reasoning and seekbar citation marks), and the "copy all observations" clipboard export. The REST API keeps serving every field.
• Mechanical: regenerated services/mcp/schema/*.json, src/tools/generated/replay_vision.ts, and the tool-schema snapshot from tools.yaml.

+        param_overrides:
+            limit:
+                default: 20
+        response:
+            exclude:
+                - scanner_snapshot.scanner_config.prompt
+                - scanner_snapshot.query
+                - scanner_result.model_output.reasoning_segments

How did you test this code?

• New services/mcp/tests/unit/vision-scanner-observations-list-trimming.test.ts drives the generated handler over a mocked API response. It catches a regression no existing test covers: the exclude paths silently no-op if a path stops matching the response shape, which is exactly how this defect would return. The schema-snapshot test only sees the input schema, and tests/unit/utils.test.ts only covers the omitResponseFields helper in isolation.
• Confirmed the test fails without the fix: removing the generated filter turns the first case red, so it is not asserting its own configuration.
• Ran tests/unit/vision-scanner-observations-list-trimming.test.ts, tool-schema-snapshots, generate-tools, and utils in services/mcp, plus lint-tool-names and hogli ci:preflight --fix (no failures).
• Not checked: pnpm typecheck in services/mcp cannot run clean in this sandbox because the nested @posthog/quill workspace is unbuilt, which errors on every product's MCP app. No error referenced the two files changed here.
• Reproduced the symptom against a live scanner through the MCP tool, but did not re-run the tool against a rebuilt server, since the change is in the checked-in generated handler.

Automatic notifications

• Publish to changelog?

Docs update

None. The tool description and agent note are the user-facing surface, and both are updated here.

🤖 Agent context

Autonomy: Fully autonomous

Written by Claude Code from a PostHog inbox report. Skills invoked: /writing-simplified-technical-english, /writing-pr-descriptions. Repo conventions for MCP tools came from services/mcp/CONTRIBUTING.md and docs/published/handbook/engineering/ai/implementing-mcp-tools.md.

Two approaches were tried before this one. The first reapplied #68360 in the DRF serializer, gated on self.action == "list". Tracing the frontend consumers showed that trims real features off four app surfaces, so it was reverted. The response.exclude mechanism in tools.yaml reaches only agent callers and is what the earlier list-overflow fixes used, so the app is untouched by design.

Two details in the report needed correcting on the way. It named vision-scanners-observations-retrieve; the tool is vision-scanners-observations-get. It also did not account for the tool's agent note, added after #68360 was written, which tells agents to read reasoning_segments off list rows to deep-link a finding. Dropping that field without rewriting the note would have left the tool documenting a field it no longer returns, so the note now describes the retrieve hop.

No duplicate: gh pr list --state open --search over both the tool name and "replay vision observations list" found no open PR fixing this. #89485 is adjacent (frontend reasoning hover) and does not touch the MCP layer.

Public artifact: the report and the live reproduction both involved real customer session content. Nothing from either reached this PR. The test fixture was written from a list of the properties it has to exercise, with the real payload closed, using an invented scanner and invented prose.

Created with PostHog Desktop from this inbox report.